《企业破局的34个锦囊》之领导者必备的技术思维
本章简要总结本书的技术部分—第11～16章。为了在数字化时代取得业务成效，这是我们认为所有领导者都需要具备的技术思维的最小集合。
1. 技术卓越至关重要
通过技术卓越提升软件内部质量，使软件系统具备高水平的灵活性、适应性和响应力，将对组织响应力产生直接、实时的影响。
然而在许多人心目中，IT仍被视为一种商品或成本中心。软件系统也通常被视为一种公共设施，常被比作水和电：打开水龙头，期待水流出来。如果想使用更多的水，可以将水龙头开大或使用更多的水龙头。所有的水都是一样的，因此企业会找最便宜的供应商。企业不会经常改变想要水的种类，因此系统最大的风险就是出现故障。系统只需要以低缺陷、高吞吐量和高可用性运行即可。
与公共设施不同，软件系统应该是企业的战略资产，需要持续地演进并与业务适配，而非“一次性的”。此时，所面临的风险不仅在于系统的运行状况，还在于系统在努力与业务保持同步的过程中遗漏了哪些事情。客户可能会要求当前产品尚未提供的新价值。新技术可能会消除一些摩擦，并带来更多便利。竞争对手可能会推出一些具有颠覆性的新功能。因此，要使业务脱颖而出，就需要能够利用软件系统，持续交付新的有差异化竞争优势的功能。更短的交付周期、更高的响应力和适应性正在成为新的竞争领域。软件内部质量是系统响应力的基础指标和驱动因素。
1.1 软件内部质量
软件内部质量是代码设计与结构的度量，通常对最终用户是不可见的。一个干净、经过良好设计、易于维护的代码库就像一个干净、经过良好整理的房间，在这样的环境中更容易找到所需的东西并保持高效工作。特别是在大型软件系统中，混乱的代码库会减慢每个人的速度，使得添加新功能或进行优化变得耗时、昂贵且在经济上不可持续。有时，你可能被迫重新构建新系统，而不是扩展当前的系统。反直觉的是，一件商品（比如汽车）拥有更高的质量（采用高质量的材料以高标准制作）时，它会更昂贵。而对于软件来说，高质量实际上意味着更便宜。
1.2 软件设计与技术债
好的设计常常受到业务领导者与技术领导者的赞赏。有经验的、技术娴熟的技术人员可以运用模式和知识，创建具有良好架构的可扩展软件设计。
与大多数非技术人员的认知相反，只有良好的前期设计是不够的。不管我们期望与否，设计都会随着时间而腐化。新的需求出现时，可能扰乱原始设计意图；开发人员编写代码时，可能引入混乱的解决方案；面临交付压力时，团队可能被迫走捷径。所有这些小事情几乎每天都在发生，它们被称为技术债。顾名思义，承担债务意味着必须支付利息，这相当于软件开发中开发新功能或维护系统所需要的额外努力。当技术债过多时，所需的额外利息将使得在原有系统上扩展功能变得不划算。
1.3 技能娴熟的工程师
使整个开发团队保持高水平的技术技能是很重要的。传统的软件工厂模式是，围绕着少数高水平工程师和一群初级技术员工（通常来自低成本的供应商），寄希望于设计是由高级工程师完成，而简单的编码任务是由初级技术员工完成的。该模式可能适用于那些需求变更非常少的工具程序，但是当组织需要软件持续演进时，它将很快崩溃。当软件不断演化和扩展时，战略性数字资产中不存在简单的编码任务。
即使拥有一支技能娴熟的技术团队，技术债仍然可能会增加。我们将在第11章讨论其原因。保持低水平技术债的开发纪律是至关重要的。通过持续检查和修改，可以花费少量努力来偿还技术债。如果开发团队足够早、足够频繁地持续执行检查和修改，就完全有可能将技术债保持在较低的水平，并逆转软件设计的腐化过程。
1.4 业务与技术领导力
管理技术债最困难的部分是在业务领导者和技术领导者之间建立建设性的关系，以在软件质量上做适量的投资。不要只关注和度量交付的功能以及需求的数量，而要让团队同时度量内部质量（如果不度量，那么对于非专业人员来说就是不可见的）。如果内部质量下降得太厉害，开发人员发现代码难以维护，或者交付速度受到影响，那么领导者应该支持团队投入时间来偿还技术债。平衡功能开发与系统内部质量是一个持续的挑战，需要技术专家和业务专家之间的信任和健康关系。投入功能和代码质量之间的工作量将是一个动态平衡，不存在静态的“正确”答案。由于它常常与业务需求（更多与更快交付）发生冲突，因此这是一个有挑战的平衡。业务领导者和技术领导者都需要不断地提醒自己：如果现在付出一点努力来偿还技术债，几个月后就会得到非常有价值的回报。我们将在第11章更深入地讨论这个主题。
2. 赋能人才
追求技术卓越需要技能娴熟的技术人员。DevOps与持续交付需要更多的多面手。平台思维和现代架构技术要求洞察最新的技术趋势。在某种程度上，所有这些都归结于人。你拥有具有完成这些任务所需的素质和数量的人才吗？
然而，整个科技行业都处于数字化人才短缺的状态，而且在未来几年内，由于需求量巨大，这种情况还将持续。这在不同的国家和业务领域都是一样的。无论我们与哪个组织对话，获得和留住数字化人才都已经成为数字化转型过程中最重要的任务之一。
当大多数技术资产被视为公共服务时，传统的管理智慧会要求尽可能多地外包。因此，许多企业将大部分软件系统（包括核心软件开发能力）外包给第三方供应商，特别是低成本的服务提供商。这不仅造成了大量的技术债，使得IT变得昂贵和响应缓慢，还失去了对技术专业知识和系统知识的洞察。
尽管人才争夺战十分激烈，但看不到任何可以忽视它的选项—建立数字化能力的需求比以往更加迫切。如果数字技术是一个未来差异点，希望自己拥有它或者与合作伙伴共同拥有它，那么当然不会再将它完全外包出去。
当谈到构建数字化能力时，我们被问到最多的问题是：“我应该去哪里以及如何雇用数字化人才？”我们认为这实际上不是最重要的起点：首先要关注的是企业内部，而不是外部。
除了外包或者角色变化（许多人从实操者变成了供应商经理）之外，大多数组织中仍然存在许多人才。
要释放这种潜力，需要关注两个关键的方面：
1.建立一种学习型文化，使得随着时间的推移，员工不断
进步。
2.营造一个赋能员工的环境，使员工更快成长。
2.1 构建学习型文化
在数字化时代，技术进步的速度越来越快，把所有人都推向了终身学习的模式。技术正以指数级的速度发展，技术人员每隔几个月或几周就需要获得新技能。学习已不再是仅在学校里做的事情，也不再是偶尔通过在职培训做的事情，它正在成为每个人日常工作的一部分。这听起来令人生畏，但也意味着从任何时候开始学习都不会太迟。
要创造一个学习型环境，组织的领导者需做很多事情。以下是一些需要考虑的方面：
1）创造针对反馈的安全环境
尽管培训是一个学习和提高的好机会，但对大多数人来说，大部分学习仍是在工作中基于同事的建议和反馈完成的。把反馈和绩效评估分割开来，这样做的目的是帮助和支持，而不是评判或批评。创造一个安全的环境来提供建设性和有效的反馈至关重要。
鼓励持续反馈
如果没有促进和鼓励，反馈就不会自然地发生。当然不应该只在正式的年度或季度周期内提供或获取反馈，而应该有规律地持续进行。团队领导者应该接受培训，学习如何给予和接受反馈，并与团队成员一起促进反馈。
2）创造针对失败的安全环境
这一点在数字化时代尤为重要，因为快速试验和快速学习的能力将决定赢家和输家。无论如何研究和设计试验，大多数试验的结果都是失败。关键是要从失败中学习，而不是试图避免失败。这与传统的规避风险的运营心态截然不同。许多组织致力于从失败中学习，有专门设计的流程和投入—损失评审、事后分析等。但这些组织的心态是：“我们失败了，这很糟糕；有人犯错了；找出是谁和做错了什么，确保其他人不会再犯同样的错误。”应该改变这种心态，用积极的眼光看待失败—从失败中学到了什么新知识（关于市场，关于技术，关于客户），并庆祝获得了这些新知识。
3）在运营压力下不削减培训与能力发展预算
大多数企业都为员工制订了培训和发展预算。培训预算的价值很难衡量，回报也不是立竿见影的。它不应是在运营压力下被削减的第一个项目，不应被视为可自由支配的支出，否则将传递完全错误的信息，即学习是可选择的，可以在任何时候停止。
4）建立一流的学习与发展职能部门
强大的学习与发展职能部门可以帮助组织为每个角色及其学科设计一个能力模型，该模型罗列了引导达到精通的发展与学习路径。在不同的成熟度阶段，应该为每个学科确定教练和导师，来为从事学习活动的人提供帮助。应该组织培训、课程、工作坊等活动来实现这些学习路径上的学习目标，而不是将其作为根据可用的预算随机分配给员工的培训“福利”或对良好绩效的奖励。
2.2 构建赋能型文化
在前面提到的《驱动力》中，自主权被列为最能激励现代知识型员工的三个关键因素之一，此外还有掌控力和使命感。人类需要感觉到他们能够控制自己的行为和目标。这是人们选择工作地点和工作内容的强大而深刻的原因。当一个人觉得自己有更多的自主权来做与工作相关的决定时，他们就会变得更有效率，更有创造力，更有动力做得更好、做得更多。
以下是一些常见的做法，可以帮助创建一个赋能的环境：
1）交流和共享信息
信息不应该像金字塔一样，只在命令链上下流动。它应该能够在节点与层级之间跳转，并且水平流动。领导者可以创建流程、工具与网络来影响这一点，以形成更多的渠道来使得信息在组织中流动，例如第6章中提到的大型可视化图表和其他信息雷达。
2）委托决策权
命令与控制式的管理哲学将大部分决策权交给了领导者，部分原因是领导者相比团队成员拥有额外的背景环境。如果每个人都能获得适当数量的信息，那么更多的人将能够做出正确的决策，而不仅仅是少数领导者。在一个自组织的团队中，领导者的职责是促进对工作中出现的新模式和行为的讨论，将每个人拥有的背景与信息可视化，让正确的决策涌现出来。这与命令和控制的风格形成了鲜明的对比，因为领导者不会事先指定正确的决策应该是什么。
3）培养主人翁意识
除了拥有决定如何做事情的权力外，强烈的主人翁意识还来自目标设定的过程。领导者将精力集中于关键目标沟通，有助于对企业和业务建立清晰的认识。应该进一步让团队自己参与进来，将关键目标分解并分配到更小的部门和团队中，以便其能够为自己的部门和团队制订目标。
关于员工招聘与保留，实际上没有什么可补充的。专注于构建培养和赋能的环境，不仅有助于释放现有员工尚未开发的潜能，让他们更好地使用数字技术，还有助于从外部招聘和留住人才。
以培养与发展数字化人才闻名的企业更容易吸引有抱负的人才。那些感觉到自己在持续学习新技能并被赋予了影响力的人不太可能为了更高的薪水而离开当前的企业。
我们对招聘的主要建议是，更多地关注激情与潜能，而不是技能。学习意愿、学习意志力与学习能力比一个良好的开端或现有的经验水平更重要。这种方式将打开更多的渠道，为优秀人才创造更多的资源，尽管这些人才在传统标准下可能显得不合常规。
最后，我们希望解决组织部门之间的合作关系，它是由以下两个因素驱动的：
l 第一，技术领域已经足够广泛与复杂，以至于任何一家企业都很难在所有领域拥有深厚的专业知识—从开发、自动化、基础设施到数据工程与机器学习。一个组织能拥有的这些专业人员的数量也是有限的。
l 第二，即使企业成功地在内部构建了差异化的核心数字化能力，持续跟随技术发展仍将是一个巨大的挑战。对这种新型技术能力的需求正呈指数级增长，超过了行业目前所能提供的水平，未来十年可能也是如此。适当的数字化咨询将为发展数字技术人才创造一个不同（但不一定更好）的环境。这种数字技术和能力的来源将通过内部能力提升、外部专业知识与人才扩展来补充内包战略。
这两个因素需要一种不同类型的能力资源获取策略—一部分来自内部，一部分来自资源共享，另一部分来自外包。虽然没有一个放之四海皆准的解决方案，但传统的以成本为导向的外包方式已经过时。数字化合作伙伴需要能够与你的数字化团队紧密合作，从而形成一个整体团队的氛围。
我们建议审查数字化合作伙伴关系的以下方面：
1）文化一致性
更深入地了解合作伙伴的组织文化，最理想的方式是相互观察对方（而不是仅仅听演讲），从前雇员或客户那里获得关于明确定义的文化行为的参考资料，以了解两种组织文化之间的一致性（或差距）。
2）流程兼容性
尽管大多数组织已经采用或开始采用敏捷研发流程，但它们难以将大量的外包人员和供应商纳入敏捷和持续交付流程中。在流程设计中，要避免“肤浅地”采用敏捷实践：要到真正的开发团队中去，查看流程和实践是否得到了正确的理解，而不只是形式上的遵循。
3)技术卓越性
除了系统设计之外，开发人员的编码技能和编码质量也会对软件系统的内部质量产生重大影响。好的设计也会因糟糕的实现而迅速腐化为不可维护的代码。组织中的所有开发人员都应该具有工匠精神，成为自己领域的大师。这也适用于数字技术合作伙伴。在寻找合作伙伴时，一定要了解这个组织的技术卓越性，特别是大多数开发者社区。不要只关注合作伙伴的质量控制流程和少数资深人员的能力。
我们将在第12章更深入地讨论这个主题。
3. 持续交付与DevOps
如果希望整个组织的战略中心转移到以快速向客户交付最大价值为目标，那么业务团队与技术团队就需要协同工作来完成端到端的“建立-试验-学习”环。关键的技术指标是尽早、快速地将软件解决方案交付到生产环境中的能力，以及快速响应变化的能力。传统的重量级软件开发方法很难做到这一点。不幸的是，尽管轻量级敏捷软件开发方法已经存在了近20年且成功地支持了这些目标，但是在大型企业中的普及还远远不足。
如果企业不熟悉敏捷软件开发方法与传统的瀑布式软件开发方法，那么这是一个向技术团队提出的好问题。如果没有被恰当地采用，那么敏捷方法将成为数字化转型的主要障碍。即使IT部门认为它正在进行敏捷软件交付，实际上它也可能需要大量的帮助来进行技术、文化和组织上的变革，从而实现真正的敏捷交付。
3.1 持续交付
敏捷方法中的持续交付概念是将软件交付过程从缓慢的节奏、较长的发布周期变为快速、增量与迭代的方式的关键。有了这个概念，团队可以确保开发的每个功能在任何时候都可以发布到生产环境中，而部署时间的决策将变为业务决策。只需按下一个按钮就可以发布更改，无须等待漫长的测试和发布周期。
为了构建持续交付客户价值的能力，产品团队需要采用一些重要的技术与实践：
l 构建包括业务人员的更小的跨职能团队。
l 将需求分解成更细粒度的、有价值的、可发布的独立单元。
l 在“迭代”中工作，在开始下一个迭代之前，从头到尾（到生产）完成一个小需求。
l 编写完全自动化的测试，创建安全的网络环境。这样，短的发布周期就可以在没有繁重的人工过程和工作的情况下得到适当的测试。
l 使用自动化技术，以一致的方式在从开发到生产的所有环境中启用“一键”部署。
l 将基础设施“作为代码”管理，以更容易地根据需要创建和重新创建环境，来消除瓶颈，实现可伸缩性和灾难恢复。
另一个重要的概念是，在产品开发团队中构建更多的通用技能集，培养更多的通用型人才，而不是仅仅依赖于专家。
在大多数技术型企业中，构建软件和运维软件被看作两种完全不同的活动，需要不同的技能集。在软件系统投入生产后，通常会有一个不同的团队来运维。该团队将管理和维护生产环境、软件配置，监视性能，并报告任何生产问题或用户投诉。如果想要频繁地发布软件并不断地更新，开发团队和运维团队就需要紧密协作。如今，移交、沟通、协调和部门间的障碍造成了许多延迟和缺陷。
3.2 DevOps
DevOps是一种文化运动，旨在解决“构建vs运维”的问题，方法是让开发部门和运维部门更紧密地协同工作，让运维专家成为开发团队的一部分。这使得运维专家能够向软件开发过程提供早期的反馈，并作为开发团队的一分子实际负责软件产品的运维。
DevOps社区中的许多人也支持在团队中创建一种新的角色：DevOps角色。我们的想法是，与其试图找到更好地协调和移交工作的方法，不如让同一个人来做这两项工作。因此，DevOps的含义是开发和运维技能在同一个角色中的融合。根据Glassdoor网站的数据，在2018年美国十大科技工作排行榜上，DevOps工程师在收入潜力、工作满意度和职位空缺数量方面仅次于数据科学家，成为第二受欢迎的工作。
这是一把双刃剑。我们不希望DevOps成为一个职位头衔，因为这会导致这样一种行为，即只有一个人应该关心开发和运维之间的衔接与协作，而团队的其他成员仍然是孤立的开发人员或运维人员。但我们确实喜欢这样的理念，即人们可以拥有跨开发和运维的多种技能。与许多其他行业一样，科技行业一直受到旨在提高大规模生产环境中生产效率的“劳动分工”概念的强烈影响。在数字化时代，生产力意味着大规模的定制化和协作，以获得速度、敏捷性和对变化的响应力。在“数字化一切”的时代，我们能够以机器速度建立和更改软件系统。而缓慢的部分就是让人类进行复杂的思考，在软件中表达思想。越快地从概念转换到代码—一个完全基于人类协作的智力活动—就能越快地将价值交付到生产。
我们将在第13章更深入地讨论这个主题。
4. 数字化平台
“平台业务”的概念吸引了不同行业许多领导者的兴趣。在数字化时代，一些成功的企业都是平台型企业（或API企业）—苹果、阿里巴巴、亚马逊、Salesforce、优步和爱彼迎（Airbnb）等。平台业务将生态系统的参与者联系在一起，表现出非线性的规模化特征。
连接生态系统中的参与者并不是一个新概念。市场在人类历史上一直存在—从古代的集市到现代的购物中心，商人和购物者在那里见面和交易。报纸也存在了几百年，广告商从大量的忠实读者中获益。除了吸引大量的受众外，现代的平台业务还为他人提速提供了基础。例如，Salesforce和亚马逊为中小型企业提供客户关系管理和实现能力，使它们能够快速成长并专注于核心价值创造。
这些现代平台业务的共同之处在于，信息技术的进步推动了数字化和线上基础设施的发展。数字技术使人与人之间的联系变得更容易、更便宜。随着所捕获的数据量的增加，平台通过新的分析技术为各方提供了更多的价值创造机会。
我们在这里讨论的数字化平台不是平台业务本身。相反，正是数字技术平台开启了商业模式革命。尽管这是必要的，但它并不总能带来平台业务。事实上，我们并不认为大多数大型企业需要成为所谓的平台型企业来差异化自己。平台业务会加速增长，但仍将是整体经济格局中的一小部分。
无论是否要扩展商业生态系统来成为一个平台型企业，从长远来看，数字技术平台总是任何现代企业所需采纳的一个关键步骤，从而能够以更快的速度、更高的质量和更低的成本向客户提供新价值。
我们认为有三大支柱支撑着数字化平台：
1)支持API的模块化架构
企业软件系统不应该是一个单体架构，而应该由细粒度服务（在技术社区中通常称为微服务）构建而成，这些服务对应于业务人员能够识别和关联的业务领域功能。例如，像“在商店中查找”这样的业务功能可以被识别为有价值的零售领域功能，并且可以在线上购物和店内购物功能中重用。这些服务由稳定的团队独立构建、部署和运行，在数字化世界中通过API公开这些业务能力。
2)自助访问数据
组织内的数据常常被锁定在孤岛中（有意的或由于技术偶然性），无法跨团队或部门访问。现代组织需要使能团队自主权，一个关键的领域是使团队能够“自助”地访问其需要的数据以创造价值。通过一致的企业级数据战略或者简单的基于API的机制，可以实现自助访问数据。自助访问数据确保团队能够快速地将价值交付给客户，而不会为了访问关键数据而陷入组织的繁文缛节中。
3)交付基础设施
团队经常为了申请服务器、数据库、网络和防火墙之类的基础设施而等待。当今最好的IT组织改进了基础设施交付，以消除技术团队可能经历的任何摩擦。这些基础设施服务包括快速自助访问计算环境、计算资源的弹性扩张、创建开发环境、创建开发工具以及创建运行时环境。目标是让产品开发团队能够快速、轻松地访问需要的工具，以更少的开销进行试验，通过更少的沟通和交接障碍获得更快的反馈。
建立一个专门的“交付基础设施”团队来为开发团队逐步构建这些服务和工具常常很有帮助。
这三个支柱似乎充满了技术细节，但在更高的层面上，它们都遵循相同的哲学。将数字化能力、数据和交付基础设施打包到服务中，组织内的所有团队都可以方便地访问这些服务。这三种类型的服务形成了市场或平台的概念。完成之后，如果以客户成效为基础的团队决定探索一个新的想法并验证市场反应，就可以快速访问所需的业务能力、获得洞察所需的数据，以及所需的交付基础设施，立即开始编码和发布新的想法。
拥有许多内置技术解决方案的大型企业通常不具备这种优势，即在高质量和低技术债的前提下，以模块化、可重用的方式构建所有东西。事实上，我们经常使用孤立的单体遗留系统架构。平台化思维的挑战不在于新能力，而在于如何打包、转换或替换这些遗留系统并以新的平台化方式工作。
为了支持数字化转型的精益切片方法，需要做一些遗留系统现代化工作。而现代化工作应该由这些精益切片需求驱动，而不是简单地替换所有遗留资产的整体需求。一般来说，每个遗留系统都有一些常用的现代化模式：
l 替换：可通过自定义代码、新功能包或软件即服务（Software-as-a-Service，SaaS）进行。
l 扩展：在旧系统的基础上添加一个新系统，并在两个系统之间进行中介请求，增加一个所有新集成都应该使用的服务接口。
l 延续：保持遗留系统运行，进行现代化改造，如添加更好的测试、更多的自动化测试，或通过API进行工业化，使其更容易跨组织重用。
针对遗留系统的改造取决于多种因素，包括技术的当前状态、（保留或替换遗留系统的）风险级别，以及基于当前业务环境和路线图的可能的未来需求。最后，遗留系统现代化战略将需要包含业务与IT之间的紧密合伙关系，以便做出最佳决策。
我们将在第14章更深入地讨论这个主题。
5. 产品胜过项目
产品是目前IT行业的一个重要流行语。生产实体产品的企业当然熟悉这个词，但现在鼓励将“产品思维”应用于各种各样的事物—数字化服务、客户体验、内部应用，甚至业务间的数据流。尽管大多数人直观地认为将面向客户的“事物”作为产品来处理是一个有用的想法，但组织中不面向客户的部分通常要落后很多。
如果把更多的应用程序、服务和数据当作产品来对待，那会是什么样子呢？产品的主要特点包括：
l 产品解决某个问题或满足某种需求。最好的产品解决了人们甚至未曾意识到的需求（还记得iPod吗？谁知道人们口袋里需要1000首歌呢？）。
l 产品与其他竞品有独特的差异性。最好的产品可能解决与其他产品相同的需求，但是通过功能集、速度、易用性或成本来突出自己。
l 产品是为一个（或一组）明确的客户设计的。功能集、质量和价格都得到调整以吸引特定的目标客户。产品团队通常会做大量的市场调研，并创建原型，确保产品符合目标客户的需求。
重要的是，产品与IT习惯的“项目思维”形成了强烈的对比，在项目思维中，任何举措都被分解为一系列具有明确范围、预算和日期的项目。一个项目是要在规定的时间内完成的，而一个产品如果能创造价值并解决客户需求，那么可能会存在很长一段时间。除了时间计划外，产品与项目之间还有以下方面的不同：
l 在项目进行过程中，项目将具备完成它所需的专业技能的人们聚集在一起。项目完成后，项目团队将被打散并重新分配到业务的其他部分。产品是由包含设计、开发、支持和改进产品所需技能的产品团队开发的。通常情况下产品团队是稳定的，其成员在一起为产品长期工作。
l 项目通常是根据估算出的投入再增加一大笔应急资金来投资的，然后将投资控制在整个预算范围内。产品通常是通过估算构建一个有用的、有价值的产品所需的团队规模来投资的，然后根据此团队规模长期投资。
l 项目是为了完成项目而不是任何其他事情。通常，启动项目是为了对更大的价值创造战略做出贡献，但是运行之后，大多数项目都聚焦于在最后期限和范围内完成。“按时、按预算”通常是衡量项目成功的标准。产品专注于为客户创造价值，只要产品是有价值的，就可以持续投入来完善它。
当每个团队都在开发一个产品，知道目标客户是谁，并且可以进行长期规划时，这些差异会在整个组织中引起深刻的变化。一个关键的好处是，在产品模式下工作的团队通常可以重新定向其工作，从而比项目团队更快地交付价值，而项目团队通常必须等待一个正式的计划和预算周期。
产品导向是一个巨大的转变，不可能一蹴而就。在这个过程中，有四个关键步骤：
1. 确定什么是组织的“产品”。
2. 用精益切片方式连接产品团队。
3. 为产品提供长期投资。
4. 创建被赋能的跨职能产品团队。
向产品导向转变无疑是一个挑战。组织架构、投资和成功的度量标准都需要改变，需要努力找到合适的产品负责人来指导所有新产品。
我们将在第15章更详细地讨论“产品思维”及其含义。
6. IT部门的未来
根据哈克特集团2017年的一项研究，基于对年收入10亿美元以上的企业的160名领导者的调查，64%的受访者表示，他们对自己的IT组织支持数字化转型的能力缺乏信心。该研究还表明，对IT能力的需求在不断增长，但实际IT工作量和IT员工数量的最大增长却发生在企业IT部门之外。业务部门似乎正在投资自己的IT能力。
这既是对IT部门的挑战，也是更好地支持这种需求和为数字化转型增加更多价值的机会。除了缺乏卓越的技术、持续交付能力、平台和人才管理能力之外，我们还看到了另外两种反模式正在妨碍IT交付更多的价值和帮助推动更多业务转型。我们想在此阐明：
l 团队职能是围绕技术和系统构建的。
l 所谓的“双速IT”概念。
围绕业务能力或客户成效建立团队
在数字化时代，随着客户期望的提高，越来越多的系统需要协调以向客户提供所需的服务和体验。在前面提到的航班延误情景中，不同的系统（如航班运营、飞机航线、机场运营、机组调度、行李跟踪、客户服务、忠诚度，甚至酒店预订）必须协同工作，才能为乘客提供最佳解决方案。来自这些系统的实时信息将通过多种渠道（包括网络、移动APP、短信和电话等）被发送给机组人员和乘客，以减少乘客的焦虑，并让机组人员做好准备。让系统彼此集成既是技术上的挑战，也是组织上的挑战。
我们已经看到，许多航空公司从以技术为导向的孤岛组织架构转向了以业务能力或成效为导向的一致性架构。为了更好地处理航班延误事件，新团队不是根据包括了业务和IT的所有相关职能的独特系统，而是围绕着不规则的运营方式来支持客户旅程。尽管这并没有完全消除对于在不同时间点有一支围绕特定IT系统的核心开发团队的需求，但是开发和集成这些系统的知识与技能在整个组织中传播得更广，而不是集中在某个地方。
“双速IT”是不可持续的
在采用敏捷软件开发技术和其他新数字技术的过程中，总是有借口不能将新技术应用到执行关键任务的核心遗留系统中。在这些系统中，安全性、稳定性和准确性被认为是更重要的，甚至可以以牺牲速度和可适应性为代价。几年前面临这一困境，一些组织接受了双速IT（麦肯锡倡导）或双模IT（Gartner倡导）概念，其中快速或模式1方法可以应用于新的数字化产品，同时仍然可以保持慢速或模式2方法以运行大型核心遗留系统。
ThoughtWorks欢迎做出改变和探索新事物的意愿，但不同意闭关自守的风险规避方法。我们接受这样一个事实，即在处理大型企业中的重大变更时，在特定的时间和特定的情况下，“双速”可能是一种必要的妥协。我们也相信现在是时候抛弃双速IT或双模IT的概念了。
大多数企业面临的一个突出问题是，在消费者希望随时随地与企业打交道的数字化世界中，系统之间的联系越来越紧密。几乎所有客户参与的前端软件都依赖于后端核心系统来为客户提供端到端的价值。为了让客户可以通过手机订购商品并在商店提货，除了移动端和电子商务系统外，还需要更新商店的库存管理、预测与补货、客户服务和忠诚度系统来实现交易。
我们已经看到太多这样的例子：数字化产品交付的快速开发-发布周期与后端系统僵硬而缓慢的传统长发布周期相冲突。双速组织最终以最慢的公分母速度前进。随着客户期望的提高和越来越多客户合作的数字化，组织和系统的任何部分都不能再隐藏于“后端”之中。所有团队都必须协同工作，以更快的速度向客户交付端到端价值。尽管某些系统可以运行得更快或更慢—这是有原因的—但所有系统都需要以适当的速度运行，以支持快速的客户价值创造。正如我们在第11章中详细讨论的，现在有许多成功模式和案例研究来帮助处理“遗留系统现代化”的复杂性。是时候接受不可避免的事实、制订计划来加速整个IT组织而不仅仅是其中的一部分了。
对于如何更好地与技术团队合作，我们为业务领导者提供了一些建议。
正如第三部分开头提到的，“业务人员需要开始使用技术语言”，现在是取得进展的时候了。我们已经看到越来越多的业务领导者足够了解技术，技术领导者也足够了解业务。如果进一步推行“通才胜过专才”的原则，我们相信新一代的业务型技术人员或技术型业务人员将会出现，并成为当下现代数字化业务的更好的领导者。
最后，我们为CEO提出了一些经典理论。无论是在旧世界还是在新的数字化世界，CEO对IT部门的效率都有很大的影响。早在1994年，《麻省理工学院斯隆管理评论》（MIT Sloan Management Review）就对CIO如何增加价值、如何成为企业的战略合作伙伴、如何“创造竞争优势、实现业务转型”注1进行了深入研究。当涉及给CEO们的建议时，该研究重点强调了以下几点：
1. 将IT和CIO定位为变革的代理人。
2. 专注于从IT中获得成效，而不是效率。
3. 将IT的业务价值制度化。
4. 建立一个包括CIO在内的执行团队。
5. 将IT作为业务整体管理，而不是附属管理。
30年前是这样，今天仍然如此。
我们将在第15章更深入地讨论这个主题。
本章概述了领导者应该熟悉的所有主题。你不需要成为每个主题的专家，但是这些技术问题是当今数字化转型的核心，至少熟悉一下是很重要的。在阅读完本章之后，你可以深入研究对组织影响最大的主题。如果在数字化转型过程中遇到了某个特定的主题，可以参考特定的章节以获得更多信息，并向你的团队提出一些好问题。接下来我们将更深入地探讨每个主题。
7. 关键点
本章要点：
l 所有领导者都需要一个最低限度的技术认知基线，了解其对数字化转型的影响。
l 理解基本的关键技术概念可以帮助你更好地应对不断增长的客户需求和变化的速度。
l 所有领导者都需要支持团队采用更严格的技术规则。
两个锦囊：
l 分享技术概念，建立技术思维：给企业领导者们设置关键技术概念的基线，并将其加入变革以及成功的愿景中。领导者和技术团队之间定期交流，以便直接帮助与支持新技术的采用。
l 发展技术人才，内建技术能力：通过能力提升和招聘来发展内部技术人才。倡导确保产出物质量的交付规则。
以上内容摘自《数字化转型：企业破局的34个锦囊》一书，经出版方授权发布
往期推荐
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。